View creation control

Hi peoples,

I was told that there is a way in DOORS to prevent users from creating public views, only private.

Something to do with access controls and shareable edit.

The main idea is to stop other departments seeing the own views I've created for my own convenience on the company-wide template. This way, a standard look is available, but what you do with it is your business, and your custom edits will not interfere anyone else.

Is this possible?

At the moment I'm working on a code to set all Public views that are not the views that I set as templatized, to Private views.

// Make all views private by removing "Everyone Else" permissions
/*string s   = ""   //Will store the name of a view
string res = ""   //Will store the returned result from a function
View   v   = null*/
 
 
View v = null
 
string viewsMRD[] = {"Attributes","Traceability","Document","Requirements"}
string viewsPTR[] = {"PTR"}
string viewsQA[] = {"Attributes","Clinical","Document","Electrical","Logistics","Manufacturing","Marketing","Mechanical","ProjMgt","QARA",Software","SyergyDOORS","SysEng","TestEng"}}
string viewsFMEA[] = {"BookView","WorkingView"}
 
string s
Item moduleitem
string modulename
 
for moduleitem in current Project do
{
    modulename = fullName(moduleitem)
 
        if((type module itmname) != "formal")
        {
                edit(modulename, false, true, false)
 
                for s in views(current Module) do    //For all views in the current module
                {
                        if(s
                        v = View s               //Handle to the current view
                        res = set(v, none, null) //set the access rights for the 'Everyone else' group to 'None'
                        if (!null res)
                {
                        print("Error setting permissions on view " s "." res "\n")
                }
                
                close(modulename,false)
        }
}

I haven't fine tuned it so you will probably find that the loops don't make sense.

But the concept is really cumbersome. If what I've been told is true, then preventing additional untemplatized public views will be a lot easier.

Thanks,

TooDiff

TooDifficult - Mon Dec 20 22:57:20 EST 2010

Re: View creation control
SystemAdmin - Tue Dec 21 00:43:50 EST 2010

Shareable edit is associated with the access rights of module objects and has nothing to do with module views so that won't help you here.

The concept of your code looks sound, but it won't stop users from saving public views and will have to be run repeatedly. Have you tested the code?

When it comes to maintaining Views that need to be common, a method to consider is to create a module that will be a template for users to copy. Create your common template views but prefix the names of the common template views with a number so that they will appear at the top of the sorted view list and in a set logical order e.g. 01 Default View, 05 Trace View, and so on. Access permissions for these views in the template module are set so that everyone can see them but only members of a special group, like an Admin group, can alter them. When users copy and paste the template module these view permissions will persist. All users are educated to prefix the names of their public views with a 2-4 char abbreviation of their name. They can view the numbered template views but cannot alter them. But they can save a numbered template view as their own public or private view and do as they please. The name prefixing groups their views together to help keep the view list neat and to also give a visual clue as to who owns what without having to dive into the "Manage Views" menu item. There will always be exceptions but I've found that most users manage to stick to this.

Paul Miller
Melbourne, Australia

Re: View creation control
TooDifficult - Tue Dec 21 16:28:56 EST 2010

Thanks for the reply,

I can't find anything relating to setting RMCDA rights for views...are they counted as access controls for the module or object level?

Since the code I supplied would have to be run every time some new user creates a view, do you think it'd be possible to use that as a trigger? Whenever a view is saved, the code will check the name against the table of set names that I put out. If it doesn't match any of the entries, it's set to a private view.

Thanks again,

TooDiff

Re: View creation control
SystemAdmin - Tue Dec 21 18:23:45 EST 2010

TooDifficult - Tue Dec 21 16:28:56 EST 2010
Thanks for the reply,

I can't find anything relating to setting RMCDA rights for views...are they counted as access controls for the module or object level?

Since the code I supplied would have to be run every time some new user creates a view, do you think it'd be possible to use that as a trigger? Whenever a view is saved, the code will check the name against the table of set names that I put out. If it doesn't match any of the entries, it's set to a private view.

Thanks again,

TooDiff

I can't find anything relating to setting RMCDA rights for views...are they counted as access controls for the module or object level?

Views are an independent entity of a module - each view can either inherit the same access rights as applied to the Module, or can have specific access rights assigned. All entities within a DOORS DB can either inherit their access rights from a parent entity, or have specific access rights assigned to them. A basic representation of the hierarchy of entities within a DOORS DB is as follows:

DB Root
  Folders (Project & Standard)
     Formal Modules
        Module Views
        Module Objects
        Module Attribute Definitions
        Module Attribute Values

So from this you can see that Module Views are considered to be an independent entity.

I would recommend having a look at the section named "Access Controls" in the DOORS DXL manual - you will find descriptions for how to get and set access rights (AR's) to any entity, as well as how to enable\disable inheritance to any entity. As for the use of Triggers - I'm no expert on DOORS triggers but from my reading of the DXL manual, DOORS does not have a trigger level for Views, so doesn't look like you can trigger on any events associated with a View.

Here's some simple code that prints out the current AR's assigned to each view within a module - might help you to understand the use of the DXL AccessRecord type - you can also view the same info via the Module menu item View > Manage Views > Access Tab - the challenge you have is to parse these AR's and work out the rules for what constitutes a View that needs to be converted to a Public View - for example, your template views must remain visible, so you need to distinguish between a template view and all other non template views.

Module m = current
string ViewName = ""
string res = ""
View v = null
AccessRec ar
string perm = ""
string msg = ""
 
 
for ViewName in views(m) do {
      v = view ViewName
      print ViewName "\n"
 
      for ar in all v do {
        msg = ""
            if null username ar then //if no user or group assigned to AR, then must be the default "Everyone else" group
                {msg = msg "\tEveryone else - "}
            else {msg = msg "\t" username ar " - "}
            if read ar then perm = "R" else perm = "None"
            if modify ar then perm = perm "M"
            if create ar then perm = perm "C"
            if delete ar then perm = perm "D"
            if control ar then perm = perm "A"
            msg = msg perm "\n"
            print msg
           }
   }

Paul Miller
Melbourne, Australia

Re: View creation control
TooDifficult - Wed Dec 22 20:51:31 EST 2010

Thanks for the reply,

I noticed in your code you supplied 'None'. Is this different from 'none'?

Also, I've been using set(v,none,"") as my perm modifier...should I start using ARs? The set function doesn't work for 'none'.

-2Diff

Re: View creation control
SystemAdmin - Wed Dec 22 22:47:51 EST 2010

TooDifficult - Wed Dec 22 20:51:31 EST 2010
Thanks for the reply,

I noticed in your code you supplied 'None'. Is this different from 'none'?

Also, I've been using set(v,none,"") as my perm modifier...should I start using ARs? The set function doesn't work for 'none'.

-2Diff

Replace "none" in set(v,none,"") with "null", so that you have set(v,null,"") - the null operator passes a null Permissions value to the set() function which is the same as selecting the "None" option when manually setting permissions via the Access tab of various dialogue boxes in the DOORS client.

Paul Miller
Melbourne, Australia